SRE の原則
運用負荷が 50 % 以下になったらリダイレクトは終了
効果的なフィードバックメカニズムにもなる
開発チームと SRE チームの構造的な対立を排除することで、生産的な協力関係を構築
構造的な対立は、イノベーションのペースと製品の安定性の間にある
SRE ではこの対立を前面に表現し、エラーバジェット (error budget) を導入することで解決 サービス所有者がシステムの状態と可用性を追跡するための主要な手段の 1 つ 監視戦略は慎重に構築する必要がある
有効な監視出力は次の 3 つ
アラート : 状況を改善するために、起こっていることもしくは起こりそうなことに応じてすぐに行動を起こす必要があることを意味 チケット : 人が行動を起こす必要があるが、すぐでなくてよいことを意味 ロギング : 情報を確認する必要はないが、診断 (diagnostic) または法的な (forensic) 目的で記録 緊急対応の有効性を評価する上で最も重要な指標は、対応チームがシステムを正常に戻すまでの時間 (= MTTR)
人が関与することで遅れが生じるので、人の関与が必要な緊急事態を避けられるシステムの方が可用性は高い
人が関与する必要がある場合でも、事前にベストプラクティスを検討して 「プレイブック」 に記録しておく方が、その場で対応を考えるよりも 3 倍程度 MTTR が向上する
停止の約 70 % が、稼働中のシステムに対する変更に起因する
この領域のベストプラクティスは、自動化で下記を達成すること 問題を迅速かつ正確に検出すること
特別なことはないが、多くのチームやサービスができていない
有機的な成長 (顧客による自然な製品選択など) と無機的な成長 (キャンペーンなど) の両方を考慮する必要
キャパシティプランニングの手順
有機的需要予測 (容量の取得に必要なリードタイムを超えたところまで)
無機需要源の需要予測への組み込み
生のキャパシティ (サーバー、ディスクなど) をサービスのキャパシティに関連付けるためのシステムの定期的な負荷テスト
可用性のために重要なので、キャパシティプランニングは SRE が行う キャパシティは高価なので、必要な時に迅速に行う必要がある
コストを考えるにあたって、リソースの効率的な使用が重要 リソースの使用は、需要 (負荷) とキャパシティ、そしてソフトウェア効率の関数
パフォーマンス悪化はキャパシティ低下であるし、一定のパフォーマンス悪化によりサービス停止が起こりうる → SRE はパフォーマンスにも注意を向ける
参考文献